Obtaining access between a terminal (a client) and a server over a network generally involves having sessions between the terminal, such as a mobile terminal, and the server. Also there exists terminal devices that internally establish sessions between the application as a client and a server that implements a protocol stack for example. A session is a series of interactions between a client and a server having a well-defined beginning and end and involving agreed-upon characteristics. Typically, a session involves a peer announcing to another peer a desire to establish a session, both peers negotiating the characteristics of the session, the peers engaging in a variety of transactions and one of the peers ending the session. The characteristics which are negotiated are typically the length of packets to be exchanged, the character sets which can be understood and manipulated and the versions of protocols which are to be used. A transaction is a basic unit of interaction and may include requesting and receiving information, aborting an ongoing session and informing a peer of a situation in an on-going session. All session operations to establish and terminate a session as well as all transactions result in events being generated and received by the peer. There are many event sources (sessions and transactions).
An active session can involve multiple transactions and so can generate multiple events. Depending on the speed at which an application can process events coming from its peer, it can happen that there are more transactions than it can process and so it receives more events than it can process. In this case, the events are queued up and wait to be processed within the context of that session. Events connected or related to the same session generally need to be processed in a specific order. In some protocols, a session can be suspended, in which state no transactions are allowed except a request to resume or to terminate the session.
Terminals, such as personal computers, obtain information from the Internet through a server, such as a gateway server. The Internet uses HTTP which is a simple request-reply protocol. Almost the only events are an HTTP request and its associated response. The operating system of the server, for example a proxy server or a mail server, runs a number of applications and so creates a number of threads to deal with them. The applications use the available threads as they are required. In the case of Internet access by a PC, it is convenient to create a thread in the server dynamically to deal with each request because the requests are independent from each other. Once the request has been processed, the thread has finished its activity and is terminated. Creating and terminating threads is a big overhead to the server.
A thread is basically a path of execution through a program and can be the smallest unit of execution that is scheduled on a processor. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler.
A thread is a single sequential flow of execution in program code and has a single point of execution. To deal with a simple process, a program comprising a single thread can be used. For more complex processes which involve running a number of applications, a program can rely on a number of threads. Operating systems usually provide thread management for the application (creation, termination and specifying the entry point: at the start of the program code).
A process consists of one or more threads and the code, data, and other resources of a program in memory. Typical program resources are open files, semaphores, and dynamically allocated memory. Each thread shares all of the resources of the process. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to “balance” the load on the central processing unit.
Each thread in a process operates independently. Unless they are made visible to each other, the threads execute individually and are unaware of the other threads in a process. Threads sharing common resources, however, must co-ordinate their work, for example by using semaphores or another method of inter-process communication.
An application in the server will use the operating system thread management service and create a number of threads to manage these sessions.
Typically when a session is established between a client and server application it is done by first establishing a socket connection. To request a socket connection the client and server typically have a sockets application program interface, i.e. a sockets API, which provides a series of system calls that application programs can invoke to request sockets connection. The sockets API is supported by most major operating systems including UNIX and Microsoft Windows. For a general discussion of the sockets interface, refer to, Internetworking with TCP/IP, volume 1, by Douglas E. Comer, Prentice-Hall, Inc. 1995, pages 335–364.
The sockets API typically serves as an interface used by applications to communicate with the TCP/IP protocol stack. Generally, the client and server programs each invoke operating system functions that set up an association between them referred to as a socket connection. The client and server applications then invoke operating system functions to send and receive information between them over a network, such as the Internet, in a similar manner to calling functions to perform ordinary input/output. The information, for example, may include graphics, data, instructions and even computer programs.
The sockets connection between the two programs uses data structures which allow access to TCP/IP services. As was said the sockets API ordinarily provides a series of system calls that application programs can invoke to request sockets connection communication services.
More specifically, the typical approach to using sockets is that a server application creates an open socket ready to accept connections at a given IP address and (possibly well known) port. Once such a socket has been created, buffer space can be allocated to store incoming connection requests. The server socket ordinarily behaves as a passive endpoint waiting for a connection request to arrive from a client. In order for a client to send a connection request to a passive socket, the socket must have a name. Therefore, names are bound to sockets and are published so that a remote client can address the named socket. To initiate a connection to a remote socket a client application ordinarily requests a connection and specifies a local (client) socket and a remote name as parameters. Multiple clients can use a single server socket. Client requests can be queued in a buffer associated with the server socket. Typically when a request is accepted from the queue, a new socket is created and the new socket is used as the server side connection endpoint with a client. In this manner, a single well known port number can be used to establish many simultaneous socket connections. A shutdown (or dose) request usually is employed to terminate a socket connection.
Sockets are created for communication between a client device and server device over a network, and in the Symbian operating system (formerly called EPOC operating system) the application establishes sockets with a sockets server (that resides within the client device) that e.g. implements the protocol stack (such as Internet Protocol) which in hierarchy is thus below the application and a sockets API. Communication is then performed over a network (e.g. Internet) to the server device (not to be confused with the sockets server which is inside the terminal device) where communication is passed through a corresponding protocol stack, through a sockets API to the application on the server device.
UMTS (Universal Mobile Telecommunications System) is a so-called “third-generation (3G),” broadband, packet-based system for transmission of text, digitized voice, video, and multimedia at data rates up to and possibly higher than 2 megabits per second (Mbps), offering a consistent set of services to mobile computer and phone users no matter where they are located in the world. In UMTS there is a possibility for applications to get various QoS (Quality of Service) from the network. Quality of Service (QoS) is the idea that transmission rates, error rates, and other characteristics can be measured, improved, and, to some extent, guaranteed in advance. QoS is of particular concern for the continuous transmission of high-bandwidth video and multimedia information, i.e. normally a high QoS is needed for real-time transmissions. Transmitting this kind of content dependably is difficult in public networks using ordinary “best effort” protocols, which normally does not have strict real-time requirements.
A QoS policy is a stored set of QoS parameters that describes how the network protocol stack should handle the network traffic generated by a particular application or a particular type of application. A QoS policy can be identified with an arbitrary identifier. A QoS policy can be applied to one or more data streams created by one or more applications. Defining a certain level of QoS, and thus a certain QoS policy typical QoS paramaters used are bandwidth, end-to-end delay, jitter, packet loss, and packet loss correlation.
In UMTS there can be several QoS pipes (PDP contexts, Packet Data Protocol) with different QoS parameters simultaneously open between the UE (User Entity) and the UMTS network. QoS requests can be made by an application (through socket API QoS extension) or a user (through a Setup Application) or by both of them. The QoS Management Entity has the important task of deciding which QoS parameters are eventually requested from the network. If both the application and the user give QoS parameters, the parameters given by the user should dominate over the parameters given by the application. However, in a terminal device establishing sockets with a sockets server implementing a protocol stack for an application as client, a problem with how to apply these parameters to the correct set of sockets in the terminal device has been identified. Currently a problem exists in that there is no general approach to identify in the terminal device, which sockets belong to a particular application. Simply knowing the port numbers, that are established for sockets between the terminal device and the network, which applications specify as part of socket calls to identify TCP/UDP protocol end-points, is not sufficient to use for identifying an application or socket over the sockets connection. The reason is that presently not all applications use well-known port numbers but some applications may randomly use different port numbers. Also IPSec (Internet Protocol Security), which is a developing standard for security at the network or packet processing layer of network communication, which when used for security reasons, hides the port numbers. Therefore, a more reliable method of identifying the owner of a socket in the socket server is needed.